Bell Operating Companies (BOCs) have shown growing interest in the deployment of the third generation digital loop carrier systems (DLCs), also called Next Generation DLCs (NGDLC) or access systems, for meeting their needs in the access network markets. In contrast to the first and second generation DLC systems (SLC-96 and SLC Series 5, respectively), these access system will be able to support a wide range of desirable features such as an Integral Synchronous Optical NETwork (SONET) fiber optic transport facility, a variety of service transport media such as twisted pair, coax, fiber, or wireless, Time Slot Interchange (TSI) for grooming and concentration, and TR-303 functionality, in addition to support of the earlier generation features. A need exists, therefore, for a network element which provides flexible interfacing to various kinds of access shelves or systems that support these features, as well as encapsulates interfaces to the access shelves.
There is a also need for generic Open Systems Interconnect (OSI) interfaces between NEs. Most of the current Operations System to Remote Digital Terminal (OS-RDT) NGDLC interfaces are based on non-OSI architectures. In the architectural structure of a NGDLC, as described by Bellcore Technical Reference TR-303, the Integrated Digital Terminal (IDT) 390 is the logical part of the Local Digital Switch (LDS) 391 that is related to a single RDT 24, as shown in FIG. 1. Operations System (OS) interfaces to the RDT will be through the LDS. FIG. 1 shows a simplified view of the OS interfaces with the RDT. The Embedded Operations Channel (EOC) 392 between the RDT 24 and the IDT 390 is terminated in the IDT. The Operations Interface Module (OIM) 393 provides the interface to the OSs. Due to the complexities involved in the design of OIM, switch vendors are waiting for the availability of open interfaces on the OSs. In the interim, a private line or a switched circuit connection through a Line Unit (LU) 394 to the Supervisory System (SS) will be used for supporting the remote operations capabilities of the RDT. References to the OS-RDT interface hereinafter generally refer to the OS.revreaction.OIM.revreaction.IDT.revreaction.EOC.revreaction.RDT interface or the SS.revreaction.LU.revreaction.IDT.revreaction.EOC.revreaction.RDT. It is expected that the OSs will have an Open Systems Interconnect (OSI) interface in the future. BOCs therefore have a strong preference for the RDT-LDS interface to be fully compatible with the evolving OS interface architectures. With the rapid increase in the number of OS communication interfaces to the Network Elements (NEs), the need for generic OSI interfaces between the NEs and the OSs is becoming more of a requirement than an objective from the BOCs perspective. Bellcore has made significant contributions in this direction by defining the Generic Interface requirements based on the OSI model.
Manufacturers of access systems generally choose between the following system designs:
a. A system that meets current non-OSI architecture requirements, and provides an upgrade path to OSI architecture when the OSs are ready. An upgrade path most likely would include hardware and software upgrades and, in some cases, possibly replacing parts of the old system with the new ones.
b. A system that meets the OSI architecture requirements at some later time, because currently most of the OS interfaces are based on a non-OSI architecture.
Neither of the above two approaches provides a smooth migration from non-OSI to OSI architectures.
A highly desirable approach is to implement the LDS-RDT interface in such a manner that it works with currently prevalent non-OSI architectures and is also compatible with the forthcoming OSI-based architecture. When the OSI-based LDS-RDT interface becomes available in the digital switches, the BOCs, therefore, will not have to incur substantial costs to replace all or part of existing equipment to achieve the desired generic interface. Differences between the non-OSI and OSI models of LDS-RDT interfaces are provided below to illustrate the advantages of using this approach.
In the non-OSI, e.g., TL1 architecture, there are only three layers (i.e., the Network, Datalink, and Physical layers), as shown in FIG. 2A. The operations application messages are mapped directly to the network layer or datalink layer of the OSI reference model. The application messages for operations in the non-OSI environment are defined using TL1. The RDTs based on the non-OSI architecture support at least one of the following two protocols: X.25 Permanent Virtual Circuit (PVC) or X.25 Switched Virtual Circuit (SVC). As an example, the following TL1 command is used to edit the information associated with a particular T1 line: EQU ED-T1::&lt;aid&gt;:&lt;ctag&gt;:::LINECDE=B8ZS
In a typical implementation (hereinafter referred to as TL1-only implementation), the RDT has an array of structures that holds all the necessary information related to T1 entities. The information contained in various fields includes the address to which that particular array element is related to in the RDT, and other parameters like the Linecode (AMI, B8ZS), framing format (SF,ESF), Sequence (D4, D1D), etc. Upon successful receipt of the command from the OS, the RDT applications modify the information associated with the appropriate field in the appropriate array element. The results of this operation are sent to the OS upon completion of the operation.
By contrast, in the OSI architecture, there are more layers and operations application messages mapped to layer 7 of the OSI reference model. The operation messages are written using Common Management Information Services (CMIS), and the Remote Operations Service (ROS) is used to support CMIS. The particular application-service-elements that provide CMIS and ROS services are referred to as CMISE and ROSE, respectively. The transfer syntax for the messager is Abstract Syntax Notation 1 (ASN.1). FIG. 2B shows the protocol stack for the NGDLC EOC. As shown in the figure, layers 3, 4 and 5 of the OSI reference model are not used, but a convergence function is provided.
The basic concept for CMISE architecture lies in defining a broad database of object classes with specific properties. All of these object classes are referred to as the Managed Object Class or Managed Support Object Class, and would be managed by a managing system. Each object class includes the following:
a) an object class label
b) a list of behavior definitions
c) a list of attributes
d) a list of actions that may be performed on it
e) a list of notifications it may issue
This entire set of information that the RDT maintains is called the Management Information Base (MIB).
CMISE uses the following two types of services supporting operations functions between the managing and the managed systems. These are (1) Management Operations Services; and (2) Management Notification Services.
The Management Operations Services can be used to request an operation to be performed on an instance of object class (e.g. "M-CREATE" service to create an instance of an object class in a managed system; "M-DELETE" service to delete an object instance in a managed system; "M-SET" service to set the values of one or more attributes of managed object class instance; and "M-ACTION" service to request a predefined action to be performed on an object class instance).
The Management Notification Services can be used by an object instance to report an event to a managing system. "M-EVENT-REPORT" service allows a managed system to report an event related to an object class instance to a managing system.
As an example of the CMIS Interface, with reference to the TL1 command discussed earlier, the associated object class is "OSI Line Termination". The hierarchical position of this object class in the MIB is as shown below:
Top
Termination Point
Line Termination
DS1 Line Termination
This hierarchical relationship determines the inheritance of characteristics such as attributes, notifications and actions, among others. In the above example, "DS1 Line Termination" object class is a subclass of "Line Termination" object class, making the "Line Termination" object class the superclass. The subclass inherits all of the characteristics of the superclass, as well as its own characteristics. The object class label for the "DS1 Line Termination" object class is "dslLineTermination". Each object class has a set of behavior definitions that specify how the instances of object class can be created or deleted. Instances of some object classes can be inherently created during system initialization without intervention from the managing system. Instances of some object classes can be created automatically by the RDT based on some predefined occurrence. Instances of some object classes can be created only by the managing system (with the CMIS "M-CREATE" service). Instances of "DS1 Line Termination" object class may be created inherently or may be created and deleted only by the CMIS "M-CREATE" and CMIS "M-DELETE" services, respectively.
Each object class has various attributes including a naming attribute and other attributes associated with that particular object class, as well as the attributes inherited from its superclass. The naming attribute for the "DS1 Line Termination" object class is "dslLineTermId". One of the attributes associated with this object class is "dslLineCode" (which would be set to AMI or B8ZS). One of the attributes inherited by this object class from the superclass is "primary Service State" (which would be set to IS or OOS). All of the attributes have various properties associated with them (e.g., whether they are read-only or read-and-write). Each object class also has a set of notifications that are reportable for the object instances using the CMIS "M-EVENT-REPORT" service. The CMIS "M-EVENT-REPORT" may be used to report the Object Creation, Object Deletion, Attribute Change, and Event Reporting for the "DS1 Line Termination" object class. Each object class also has a list of actions that the object instances may be asked to perform by using the CMIS "M-ACTION" service. One of the actions the "DS1 Line Termination" object class supports is "Restore" which happens to be inherited from the superclass.
Referring back to the example of editing information associated with a particular T1, in a typical CMISE Implementation (hereinafter referred to as CMISE-only implementation), the CMIS M-SET service would be invoked for the specified "dslLineTermId" with the "dslLineCode" attribute set to B8ZS. A comparison of how the same operation is performed in a TLl-only implementation and a CMISE-only implementation will now be made. The same TL1 command given above is presented again with a simple change as follows : EQU ED-T1::&lt;aid&gt;:&lt;ctag&gt;:::LINECDE=B8ZS, FMT=ESF
The TLl-only implementation handles the above command in the same way as it did the previous command, except that it will modify two fields instead of one field in the appropriate MIB array element. The CMISE-only implementation uses two CMIS M-SET service messages to get the equivalent effect. The reason is that the "dslFrameFormat" attribute belongs to another object class (other than "DS1Line Termination" object class), namely the "DS1 Framed Path Termination" object class. Both the M-SET service messages are treated independently.